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Why yet another Apple II disk image format? 

This is probably the question many of you reading this document are asking. It basically 
comes down to the simple fact that none of the currently existing formats accurately represent 
the way data is encoded on an Apple II floppy disk. There is a place for a format that is an 
accurate representation of a bitstream that is also the exact length of a track so that it can be 
looped correctly. And since we are creating a format, it is also a great time to ensure that we 
organize the data in the image file in a way that allows for easy unpacking with as little 
memory and processing overhead as possible - this provides more performant usage in 
hardware and software emulators. 


What benefits come with using the WOZ format? 

We seem to be doing just fine with the current file formats, why would we want to support 
the WOZ format? The big benefit is being able to successfully run copy protected software if 
you follow the emulation guidelines presented in this document. The second benefit is that 
the WOZ format is actually much simpler to implement than many of the other disk image 
formats. WOZ files also contain metadata about the disk image - such as disk name, product 
name, publisher, system requirements and language - that you can use to display additional 
information in your emulator. 


Implementation Details 

Integrating WOZ support with your product is more than just loading data from a new type 
of container. It is also about how that data is used. Yes, it is possible to just shovel bits from 
the WOZ right into your bitstream, and many disk images will work just fine like that. But, by 
taking the following guidelines into account, your implementation will enable disk 
functionality that is also compatible with all copy protection schemes. Yes, this means you can 
run copy protected software in system and disk drive emulators without the need to crack it first! 


Cross-Track Synchronization 

When Steve Wozniak was hacking up Shugart drives to make the Disk II, one of the parts that 
he threw away was the sync sensor. The sync sensor involved a light source on one side of the 
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disk with a sensor on the other. This sensor would allow the drive to know when it made a 
full revolution, as the disk media itself had a hole that would let the light pass though as it 
passed the sensor. It really wasn't a necessary part for Wozniak's soft-sectored design that 
was going to be used for storing data on the disk. 



A NORMAL UNSYNCHRONIZED DISK VS A SYNCHRONIZED ONE. 


When it came to businesses designing copy protection schemes, this was something that they 
could use to their advantage. The professional disk copiers could easily write out all tracks 
synchronized with each other, something that your average Apple II floppy drive couldn't do. 
Then, the software would read a known sector on a specific track and, when it jumped to a 
neighboring track, it could make sure that the first sector it encountered there was the one it 
expected. Later protection schemes even made track widths which were almost 2 standard 
tracks wide and were accurate to within 1 bit. As much as the disk copy programs tried, they 
could only sync up tracks by sheer luck. 

To circumvent these kind of copy protection checks, the WOZ format uses a Track Map (see 
the "TMAP Chunk" section below). This allows us to assign a track image to any number of 
quarter tracks on a disk. An entire disk could even be a single track if we wanted. 

There are a couple of rules to follow with regards to changing tracks within the emulator: 

Firstly, if the tracks you are changing between have matching values in the TMAP, then don't 
change the track data. This will prevent any hiccups in the bitstream and can be a good 
performance gain to boot. 
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The second rule is that you need to maintain a bit pointer into your bitstream. You always 
need to know which bit you are on. When you do change tracks, you need to start the new 
bitstream at the same relative bitstream position - you cannot simply start the pointer at the 
beginning of the stream. You need to maintain the illusion of the head being over the same 
area of the disk, just shifted to a new track. 

Also be sure to account for the fact that track lengths are inconsistent on a disk due to 
fluctuations in drive speed. Something like this works well to maintain the relative position if 
your environment can work with 32-bit or greater values: 

new position = current position * new track length / current track length 

Remember to maintain the bit position even when on an empty track (TMAP value of OxFF). 
Since the empty track has no data, and therefore no length, using a fake length of 51,200 bits 
(6400 bytes) works very well. 


Freaking Out Like a MC3470 

On the Apple II, floppy disk data is written to the disk based on a 4gs clock. Whenever there 
is a 1 bit to write, the polarity of the magnetic flux under the drive head is transitioned from 
its current state to the opposite. If a zero needs to be written out, the 4gs clock is skipped (no 
transition occurs). 

The MC3470 chip is the heart of the Apple II floppy drive. It reads the magnetic flux pattern 
off the disk and sends out a pulse for every flux transition it sees. This gives us back our 1 bits 
and our 0 bits come from the 4jus clock going by with no pulse. 

One of the nice features of the MC3470 is that it has an internal amplification system to adapt 
to the varying magnetic strengths of each disk. If it has a hard time reading the disk, it can 
turn up its amp until it finds the signal. It allows the drive to read a wide assortment of disks. 
The Apple II uses GCR encoding to store bits on the disk. It is a very efficient system that was 
used widely on many platforms, because it doesn't use clock bits to frame up your data bits, 
giving you more room to write data. This technique also has a drawback though, which is 
never being able to record more than two 0 bits in a row. It is why data on an Apple II is 
stored as nibbles instead of plain binary bytes. 

One very popular copy protection is referred to as "fake bits" or "weak bits" - this technique 
is actually an exploit against the MC3470. It comes from the idea of what happens when we 
make it read more than two 0 bits in a row. What happens is that our poor MC3470 thinks that 
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it is doing a bad job reading the disk and keeps trying to turn up its amp to find the flux 
signal. It does this until it gets to the point that it amplifies background electrical noise so 
much that it thinks that it sees a transition and sends out a false pulse, which the computer 
happily records as a 1 bit. 

So, how can this failure be used as copy protection? The software developers simply put these 
blank fake bit areas on the disk where the software knows where to find them. It then reads 
some good nibbles followed by the fake bits area. This gives us some good nibbles followed 
by some random valued nibble. This in itself is not particularly useful until you do it multiple 
times and see that the random nibble changes every time you read it! If the value keeps 
changing, then you know that it isn't a copy of the disk. How does it know that? Because 
programs like Copy 11+ and Locksmith will read those same good nibbles followed by the 
random nibble, and then they will promptly write out all of the nibble values that they 
captured, thinking that they are all good. The random nibble is no longer random, it will 
never change from the value that has been captured, and now the copy protected software 
will know that it is actually a copy. 

So how does the WOZ format deal with this? Well, the first part of the problem isn't taken 
care of within the WOZ format itself. The WOZ format is an offshoot of the Applesauce 
Floppy Drive Controller project. The Applesauce has a way to determine when it is seeing 
these fake bits and changes the fake bits back to the 0 bits that existed on the original disk. 

Now that we are back to having long runs of Os in the bitstream, we now need to emulate the 
MC3470 freaking out about them. The recommended method is that once we have passed 
three 0 bits in a row from the WOZ bitstream to the emulated disk controller card, we need to 
start passing in random bits until the WOZ bitstream contains a 1 bit. We then send the 1 and 
continue on with the real data. 

Of course, coming up with random values like this can be a bit processor intensive, so it is 
adequate to create a randomly-filled circular buffer of 32 bytes. We then just pull bits from 
this whenever we are in "fake bit mode". This buffer should also be used for empty tracks as 
designated with an OxFF value in the TMAP Chunk (see below). 
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WOZ File Format Specification 


A WOZ file uses a chunk-based file binary format that provides future-proof expandability in 
a way that is safe for older software which may not recognize newer data chunks. 

All data is stored little-endian. 

WOZ files begin with the following 12-byte header in order to identify the file type as well as 
detect any corruption that may have occurred. The easiest way to detect that a file is indeed a 
WOZ file is to check the first 8 bytes of the file for the signature. The remaining 4 bytes are a 
CRC of all remaining data in the file. This is only provided to allow you to ensure file 
integrity and is not necessary to process the file. If the CRC is 0x00000000, then no CRC has 
been calculated for the file and should be ignored. The exact CRC routine used is shown in 
Appendix A, and you should be passing in 0x00000000 as the initial crc value. 


Byte Value 

Purpose 

0 

57 4F 5A 31 

The ASCII string ‘WOZ1’. 0x315A4F57 

4 

FF 

Make sure that high bits are valid (no 7-bit data transmission) 

5 

0A 0D 0A 

LF CR LF - File translators will often try to convert these. 

8 

XX XX XX XX 

CRC32 of all remaining data in the file. The method used to 
generate the CRC is described in Appendix A. 


After the header comes a sequence of chunks which each contain information about the disk 
image. Using chunks allows for the WOZ disk format to provide forward compatibility as 
chunks can be added to the specification and will just be safely ignored by applications that 
do not care (or know) about the information. For lower-performance emulation platforms, the 
primary data chunks are all located in fixed positions so that direct access to data is possible 
using just offsets from the start of the file. 

All chunks have the following structure: 


Offset 

Size 

Name 

Usage 

+0 

4 bytes 

Chunk ID 

4 ASCII characters that make up the ID of the chunk 

+4 

uint32 

Chunk Size 

The size of the chunk data in bytes. 

+8 


Chunk Data 

The chunk data. 
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To process the file, you start at the first Chunk ID which will be located at byte 12 of the file, 
immediately following the header. You read the Chunk ID and the Chunk Size following it. If 
you want to process this chunk, then your file pointer will be at the start of the data. If you 
don't care about this chunk, then skip the number of bytes as Chunk Size indicates and you 
will now be at the next Chunk ID. 


while(data stream.availableToRead() > 8) { 

uint32 t chunk id = data stream.readU32(); 
uint32 t chunk size = data stream.readU32(); 
switch(chunk id) { 
case INFO_CHUNK_ID: 

// read the INFO chunk 
break; 

case TMAP_CHUNK_ID: 

// read the TMAP chunk 
break; 

case TRKS_CHUNK_ID: 

// read the TRKS chunk 
break; 

case META_CHUNK_ID: 

// read the META chunk 
break; 
default: 

// no idea what this chunk is, so skip it 
data stream.skip(chunk size); 

} 

} 
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INFO Chunk 


The first chunk in an Applesauce file is always an 'INFO' chunk. This contains some 
fundamental information about the contained image. The data of the 'INFO' chunk begins at 
byte 20 of the file and is 60 bytes long (pad chunk with zeros to full length). 


Byte 

Offset 

Type 

Vers 

Name 

Usage 

12 

uint32 


‘INFO’Chunk ID 

0x4F4 64E4 9 

16 


uint32 


Chunk Size 

Size is always 60. 

20 

+0 

uint8 

1 

INFO Version 

Version number of the INFO chunk. 

Current version is 1. 

21 

+1 

uint8 

1 

Disk Type 

1 =5.25, 2 = 3.5 

22 

+2 

uint8 

1 

Write Protected 

1 = Floppy is write protected 

23 

+3 

uint8 

1 

Synchronized 

1 = Cross track sync was used during imaging 

24 

+4 

uint8 

1 

Cleaned 

1 = MC3470 fake bits have been removed 

25 

+5 

UTF-8 
32 bytes 

1 

Creator 

Name of software that created the WOZ file. 
String in UTF-8. No BOM. Padded to 32 bytes 
using space character (0x20). 
ex: “Applesauce vl .0 


The chunk is versioned to allow for adding additional info in the future. The "Vers" field in 
the table above indicates at which version the data field became available. When reading data 
from the chunk, make sure that value you are looking for actually exists within the version of 
the chunk you are reading. 


TMAP Chunk 

The 'TMAP' chunk contains a track map. This allows you to map physical drive tracks with 
the track data contained within the image file 'TRKS' chunk. This system is used because, on 
a 5.25 drive, the physical drive head is larger than the width of the written track and so the 
track is also visible from neighboring quarter tracks. For example, the data of track 1.00 is 
actually visible while reading from track 0.75 or 1.25. Instead of storing copies of track data 
for every possible quarter track, we use the map to point multiple quarter tracks to a single 
track image. 


Track 

0.00 

0.25 

0.50 

0.75 

1.00 

1.25 

1.50 

1.75 

2.00 

2.25 

2.50 

2.75 

3.00 

Maps 

00 

00 

FF 

01 

01 

01 

FF 

02 

02 

02 

FF 

03 

03 
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The data of the 'TMAP' chunk begins at byte 88 of the file and is 160 bytes long. 

Each map entry contains an index number for the track data contained within the 'TRKS' 
chunk. If the map entry is 0, then the correct track data to be using is the first entry in the 
'TRKS' chunk. Any blank tracks are given a value of 255 (OxFF) in the map and the emulator 
should be outputting random bits in this case. 

The mapping changes slightly between 5.25 and 3.5 disks. This is the format for the table for 
the layout of a 5.25 disk. The table only shows to track 35, but can also accommodate 40 track 
disks. All unused map entries should have a 255 (OxFF) value. 


Byte 

Offset 

Type 

Name 

Usage 

80 

uint32 

‘TMAP’Chunk ID 

0x50414D54 

84 

uint32 

Chunk Size 

Size is always 160. 

88 

+0 

uint8 

Track 0.00 

Index of TRKS entry to use for Track 0.00. 

89 

+1 

uint8 

Track 0.25 


90 

+2 

uint8 

Track 0.50 


91 

+3 

uint8 

Track 0.75 


92 

+4 

uint8 

Track 1.00 






228 

+140 

uint8 

Track 35.00 


the mapping for 3.5 disks: 

Byte 

Offset 

Type 

Name 

Usage 

80 

uint32 

‘TMAP’Chunk ID 

0x50414D54 

84 

uint32 

Chunk Size 

Size is always 160. 

88 

+0 

uint8 

Side 0, Track 0 

Index of TRKS entry to use for Side 0, Track 0. 





167 

+79 

uint8 

Side 0, Track 79 


168 

+80 

uint8 

Side 1, Track 0 






247 

+159 

uint8 

Side 1, Track 79 
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TRKS Chunk 


The 'TRKS' chunk contains the data for all of the unique tracks. Each track has a fixed length 
of 6656 bytes and are tightly packed into the chunk. The data of the 'TRKS' chunk begins at 
byte 256. For more efficient track data copying, all track data starts on 256 byte boundaries 
relative to the file start. Starting locations of tracks can be calculated using (tmap_value * 
6656) + 256. 


Byte Offset Type 

Name 

Usage 

248 

uint32 

‘TRKS’Chunk ID 

0x534B5254 

252 

uint32 

Chunk Size 


256 +0 

TRK 

Track 00 

First track in track array. TMAP value of 00. 

6912 +6656 

TRK 

Track 01 

Second track in track array. TMAP value of 01. 

13568 +13312 

TRK 

Track 02 

Third track in track array. TMAP value of 02. 






The structure of the TRK type in the previous table is as follows: 


Offset 

Size 

Name 

Usage 

+0 

6646 bytes 

Bitstream 

The bitstream data padded out to 6646 bytes 

+6646 

uintl6 

Bytes Used 

The actual byte count for the bitstream. 

+6648 

uintl6 

Bit Count 

The number of bits in the bitstream. 

+6650 

uintl6 

Splice Point 

Index of first bit after track splice (write hint). If no 
splice information is provided, then will be OxFFFF. 

+6652 

uint8 

Splice Nibble 

Nibble value to use for splice (write hint). 

+6653 

uint8 

Splice Bit Count 

Bit count of splice nibble (write hint). 

+6654 

uintl6 


Reserved for future use. 


The bitstream data is the series of bits recorded from the floppy drive and normalized to 4gs 
intervals. The bits are packed into bytes, but the bytes will not necessarily be representative of 
nibble values as timing bits are also represented within the bitstream. When processing the 
bitstream, the order of bits within each byte is high to low, meaning the high bit goes first and 
the low bit is last. Since this bitstream is the flow of data directly from the floppy drive, it will 
need to pass through a Logic State Sequencer as found on the Disk II Interface Card, Apple 
5.25 Drive Controller Card or IWM chip to create nibbles. But, due to the fact that the 
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bitstream timing has already been normalized, you can use a very lightweight 
implementation of one. The Logic State Sequencer performs the function of converting the 
bitstream to a nibble stream as well enforcing the proper nibble timing that many copy 
protection schemes will check. 

If you are creating a floppy drive emulator for use with a real Apple II, then you will simply 
be stepping to the next bit in the bitstream every 4gs. If the bit has a 1 value, then you send a 
ljus pulse on the RDDATA line. 

If the Cleaned value of the 'INFO' chunk is 1, then any fake bits generated by the MC3470 
during the imaging process will have been removed and replaced with 0 bit values (see the 
Implementation Details section for proper handling of these). 

The Splice information in the TRK structure is used when writing the track to a physical 
floppy disk. It points to the bit where you should start the write stream. To ensure a clean gap 
1, you are also provided with a nibble value and bit count for the nibbles that you should be 
writing as the leader before the write stream. For a normal DOS 3.3 disk, the leader would be 
128 FF/10 nibbles. 
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META Chunk (optional) 


The 'META' chunk contains metadata for the disk image and its existence is optional in the 
WOZ file. The metadata is stored as a tab-delimited UTF-8 list of keys and values. Rows are 
separated by a linefeed character ('\n' OxOA) and columns by the tab character ('\t' 0x09) 


Byte Offset 

Type 

Name 

Usage 

- 

uint32 

‘META’ Chunk ID 

0x4154454D 

- 

uint32 

Chunk Size 

Length of the metadata string in bytes. 

+0 

String 

Metadata 

Metadata string in UTF-8. No BOM. 


This is the list of standard metadata keys. Multiple values are pipe-separated. 


Key 

Purpose 

Example Value 

title 

Name/Title of the product. 

Prince of Persia 

subtitle 

Subtitle of the product. 


publisher 

Publisher of the software. 

Broderbund Software, Inc. 

developer 

Developer of the software. Pipe- 
delimited list if needed. 

Jordan Mechner 

copyright 

Copyright date. Free form text 
allowed. 

1989 

1987 Muse Software 

version 

Version number of the software. Free 
form text allowed. 

1.0 

19870115P 

language 

Language (see table A) 

English 

requires ram 

RAM requirements (see table B) 

64K 

requires machine 

Which computers does this run on? 
Pipe-delimited list, (see table C) 

2+l2el2cl2gs 

notes 

Additional notes. 


side 

Physical disk side formatted as: 
“Disk#, Side [AIB]” 

Disk 1, Side A 

side name 

Name of the disk side. If the disk side 
is named on the label like Player, 

Town, Dungeon, etc then it goes 
here. 

Front 

contributor 

Name of the person who imaged the 
disk. 

Mr. Pirate 

image date 

ISO8601 date of the imaging. 

2018-01-07T05:00:02.511Z 
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If a standard key has no value, then the value will be an empty string. Key names are case- 
sensitive. Values cannot contain pipe, linefeed or tab characters. It would also be a good idea 
to keep all values as ASCII-friendly as possible to ensure compatibility with the widest range 
of devices that will consume these files. No duplicate keys are allowed and key order does 
not matter. Standard keys that have values laid out in the tables below cannot have values 
other that those shown below. Implementors are free to add additional keys to the metadata 
as long as they follow the same rules laid out here. 

TABLE A - LANGUAGES 


English 

Spanish 

French 

German 

Chinese 

Japanese 

Italian 

Dutch 

Portugese 

Danish 

Finnish 

Norwegian 

Swedish 

Russian 

Polish 

Turkish 

Arabic 

Thai 

Czech 

Hungarian 

Catalan 

Croatian 

Greek 

Hebrew 

Romanian 

Slovak 

Ukranian 

Indonesian 

Malay 

Vietnamese 

Other 



TABLE B - REQUIRES_RAM 


16K 

24K 

32K 

48K 

64K 

128K 

256K 

512K 

768K 

1M 

1.25M 

1.5M+ 

Unknown 





TABLE C - REQUIRES_MACHINE 


2 

2+ 

2e 

2c 

2e+ 

2gs 

2c+ 

3 

3+ 
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Appendix A: CRC Routine 


The integrity of the WOZ files are protected by a standard 32-bit CRC. The routine that has 
been chosen for use originated with Gary S. Brown in 1986 and is implemented as follows: 


static 


uint32 t crc32 tab 


0x00000000, 
0xe963a535, 
0x09b64c2b, 
Oxf3b9714 8, 
0xl36c9856, 
OxfaOf3d63, 
0x3c03e4dl, 
0xdbbbc9d6, 
0x26d930ac, 
0xcfba9599, 
0x2f6f7c87, 
0x98d220bc, 
0x7807c9a2, 
0x91646c97, 
0x6c0695ed, 
0x8bbeb8ea, 


0x77073096, 
0x9e6495a3, 
0x7ebl7cbd, 
0x84be41de, 
0x646ba8c0, 
0x8d080df5, 
0x4b04d447, 
Oxacbcf940, 
0x51de003a, 
0xb8bda50f, 
0x58 684cl1, 
0xefd5102a, 
OxOfOOf934, 
0xe6635c01, 
0xlb01a57b, 
0xfcb9887c, 


0x4db26158, 
0xa4dlc4 6d, 
0x44042d73, 
OxbeOblOlO, 
0x5edef90e, 


0x3ab551ce, 
0xd3d6f4fb, 
0x33031de5, 
0xc90c2086, 
0x2 9d9c998, 


0xb7bd5c3b, 
0xead54739, 
0x0d6d6a3e, 
OxfOOf9344, 
0x196c3671, 
Oxf9b9df6f, 
0x38d8c2c4, 
0xd80d2bda, 


0xc0ba6cad, 
0x9dd277af, 
0x7a6a5aa8, 
0x8708a3d2, 
0x6e6b06e7, 
0x8ebeeff9, 
0x4fdff252, 
Oxaf0alb4c, 


0x316e8eef, 
0xcc0c7795, 
0x2bb45a92, 
0x9b64c2b0, 
0x72076785, 
0x92d28e9b, 
0x68ddb3f8, 
0x88085ae6, 
0x616bffd3, 
0xa7 672 661, 
0x40df0b66, 
Oxbdbdf21c, 
0x54de5729, 
0xb40bbe37, 


0x4669be79, 
0xbb0b4703, 
0x5cb36a04, 
0xec63f22 6, 
0x05005713, 
0xe5d5be0d, 
0xlfda836e, 
OxffOf6a70, 
0xl66ccf45, 
0xd06016f7, 
0x37d83bf0, 
0xcabac28a, 
0x23d967bf, 
0xc30c8eal, 


0xee0e612c, 
0x0edb8832, 
0xe7b82d07, 
0xladad47d, 
0xfd62f97a, 
0x3b6e20c8, 
0xd20d85fd, 
0x32d86ce3, 
0xc8d75180, 
0x2802b89e, 
0xcl611dab, 
0x71bl8589, 
0x9609a88e, 
0x6b6b51f4, 
0x8208f4cl, 
0x62ddlddf, 
0xa3bc0074, 
0x4369e96a, 
0xaa0a4c5f, 
0x57 68b525, 
0xb0d09822, 
0xedb88320, 
0x04db2615, 
0xe40ecfOb, 
OxleOlf2 68, 
Oxfed4lb7 6, 
0xl7b7be43, 
0xdlbb67f1, 
0x36034af6, 
0xcb61b38c, 
0x220216b9, 
0xc2d7ffa7, 
0x756aa39c, 
0x95bf4a82, 
0x7cdcefb7, 
0x81bel6cd, 
0x66063bca, 
0xa00ae278, 
0x4969474d, 
0xa9bcae53, 
0x53b39330, 
0xb3667a2e, 
0x5a05dflb. 


0x990951ba, 
0x79dcb8a4, 
0x90bfld91, 
0x6ddde4eb, 
0x8a65c9ec, 
0x4c69105e, 
0xa50ab56b, 
0x45df5c75, 
0xbfd06116, 
0x5f058808, 
0xb6662d3d, 
0x06b6b51f, 
0xel0e9818, 
0xlc6c6162, 
Oxf50fc457, 
0xl5da2d49, 
0xd4bb30e2, 
0x346ed9fc, 
0xdd0d7cc9, 
0x206f85b3, 
0xc7d7a8b4, 
0x9abfb3b6, 
0x73dcl683, 
0x9309ff9d, 
0x6906c2fe, 
0x89d32be0, 
0x60b08ed5, 
0xa6bc57 67, 
0x41047a60, 
0xbc66831a, 
0x5505262f, 
0xb5d0cf31, 
0x026d930a, 
0xe2b87al4, 
OxObdbdf21, 
Oxf6b9265b, 
0xll010b5c, 
0xd70dd2ee, 
0x3e6e77db, 
0xdebb9ec5, 
0x24b4a3a6, 
0xc4 614ab8, 
0x2d02ef8d 


0x07 6dc419, 
0xe0d5e91e, 
0xldb71064, 
Oxf4d4b551, 
0xl4015c4f, 
0xd56041e4, 
0x35b5a8fa, 
0xdcd60dcf, 
0x21b4f4b5, 
0xc60cd9b2, 
0x7 6dc4190, 
0x9fbfe4a5, 
0x7f6a0dbb, 
0x856530d8, 
0x65b0d9c6, 
0x8cd37cf3, 
0x4adfa541, 
0xad67884 6, 
0x5005713c, 
0xb966d409, 
0x59b33dl7, 
0x03b6e20c, 
0xe3630bl2, 
0x0a00ae27, 
Oxf7 62575d, 
0xl0da7a5a, 
0xd6d6a3e8, 
0x3fb506dd, 
Oxdf60efc3, 
0x256fd2a0, 
0xc5ba3bbe, 
0x2cd99e8b, 
0x9c0906a9, 
0x7bbl2bae, 
0x8 6d3d2d4, 
0x6fb077el, 
0x8f659eff, 
0x4e048354, 
0xaedl6a4a, 
0x47b2cf7f, 
0xbad03605, 
0x5d681b02, 


0x706af48f, 
0x97d2d988, 
0x6ab020f2, 
0x83d385c7, 
0x63066cd9, 
0xa2 677172, 
0x42b2986c, 
0xabdl3d59, 
0x56b3c423, 
0xbl0be924, 
0x01db7106, 
0xe8b8d433, 
0x08 6d3d2d, 
0xf262004e, 
0xl2b7e950, 
0xfbd44c65, 
0x3dd8 95d7, 
0xda60b8d0, 
0x270241aa, 
0xce61e49f, 
0x2eb40d81, 
0x74bld29a, 
0x94 643b84, 
0x7d07 9ebl, 
0x806567cb, 
0x67dd4acc, 
0xaldl937e, 
0x48b2364b, 
0xa867df55, 
0x5268e236, 
0xb2bd0b2 8, 
0x5bdeaeld, 
0xeb0e363f, 
0x0cb61b38, 
OxfId4e242, 
Oxl8b74777, 
0xf862ae69, 
0x3903b3c2, 
0xd9d65adc, 
0x30b5ffe9, 
0xcdd70693, 
0x2a6f2b94, 


uint32_t crc32(uint32_t crc, const void *buf, size_t size) 

{ 

const uint8_t *p; 
p = buf; 

crc = crc A ~0U; 
while (size--) 

crc = crc32_tab[(crc A *p++) & OxFF] A (crc >> 8); 
return crc A ~0U; 

} 
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